REMARKS/ARGUMENTS 



Amendments were made to the specification to correct errors and to clarify the specification. No 
new matter has been added by any of the amendments to the specification. 

Claims 1-23 are pending in the present application. By this Response, claims 1, 2, 4, 5, 8-10, 12, 
16-18, 20, and 23 are amended. Claims 1, 9, and 17 are amended to recite "executing the computer 
program and incrementing respective hardware counters when the plurality of addresses are accessed and 
a performance indicator associated with the plurality of addresses is encountered." Support for this 
amendment may be found at least on page 81, line 14, to page 82, line 13. A description of a performance 
indicator is provided on page 31 lines 8-15 and on page 32, lines 10-12. Claims 2, 4, 5, 8, 10, 12, 16, 18, 
20 and 23 are amended for clarity by providing proper antecedence. Reconsideration of the claims in 
view of the above amendments and the following remarks is respectfully requested. 

I. Examiner Interview 

Applicants thank Examiner Savla for the courtesies extended to Applicants' representative during 
the June 1, 2006 telephone interview. During the interview, suggestions to amend the present application 
to overcome the 35 U.S.C. § 101 rejection were discussed. Claim 8 is amended to recite "A computer 
program product in a computer readable recordable-type medium. . Examiner Savla stated these 
amendments would overcome the 35 U.S.C. § 101 rejection. Also during the interview, proposed 
amendments to claims 1, 9 and 17 were discussed. Examiner Savla stated he would consider the 
proposed amendment. Examiner Savla also pointed out a discrepancy with the claimed "one or more 
addresses" and "a combination of values obtained from the hardware counters." The Examiner suggested 
amending the claims to state "a plurality of addresses." Applicants have incorporated the suggested 
amendments. The substance of the interview is summarized in the remarks of sections that follow. 

II. 35 U.S.C. S 101 

The Office rejects claims 9-16 under 35 U.S.C. § 101 as being directed towards non-statutory 
subject matter. By this response, claim 9 is amended to recite "A computer program product in a 
computer readable recordable-type medium. . ." 

Therefore, Applicants respectfully submit that independent claim 9 is statutory. Thus, Applicants 
respectfully request withdrawal of the rejection of claims 9 and 10-16 under 35 U.S.C. § 101. 
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III. 35 U.S.C. S 103> Alleged Obviousness - Claims 1-2, 4. 8-10> 12, 16-18, 20. and 23 



The Office rejects claims 1-2, 4, 8-10, 12, 16-18, 20, and 23 under 35 U.S.C. § 103(a) as being 
unpatentable over Pekarich et al. (U.S. Patent No. 6,549,998 Bl) in view of IBM Technical Disclosure 
"Hardware Cycle Based Memory Residency," hereinafter "IBMTD". This rejection is respectfully 
traversed. 

As to claim 1 , the Office states: 

As per claim 1 , Pekarich discloses a method in a data processing system for 
processing instructions, the method comprising: 

receiving a threshold value and an identification of one or more addresses to be 
monitored during the execution of a computer program (col. 4, lines 61-63; col.3, lines 7- 
12; col. 1, lines 32-42) 

Pekarich does not expressly disclose associating hardware counters with the one 
or more addresses; 

executing the computer program and incrementing respective counters when the 
one or more addresses are accessed; 

and performing an action in response to a determination that a predefined 
relationship between the threshold value and a combination of values obtained from the 
hardware counters is present. 

IBMTD discloses associating hardware counters with the one or more addresses 
(pg. 1, paragraph 3, lines 1-2); It should be noted that each page is associated with a page 
fiame table which in turn is associated with physical addresses. 

executing the computer program and incrementing respective counters when the 
one or more addresses are accessed (pg. 1, paragraph 3, line 1-2; pg. 1, paragraph 5, line 
3); 

and performing an action in response to a determination that a predefined 
relationship between the threshold value and a combination of values obtained from the 
hardware counters is present (pg. 1, paragraph 5, lines 8-10). It should be noted that 
"page given immediately to the application requesting it when LRU runs" is analogous to 
"performing an action", "the difference between the hardware counter and the PFT 
counter is greater than the threshold" is analogous to "a predefined relationship between 
the value and a combination of values obtained from the hardware counters being resent", 
and "the difference between the hardware counter and the PFT counter" is analogous to 
"combination of values obtained from hardware counters." 

Office Action dated March 13, 2006, pages 5-6. 

Amended claim 1, which is representative of the other rejected independent claims 9 and 17 with 

respect to similarly recited subject matter, reads as follows: 

1 . A method in a data processing system for processing instructions, the method 
comprising: 

receiving a threshold value and an identification of a plurality of addresses to be 
monitored during the execution of a computer program; 

associating hardware counters with the plurality of addresses; 

executing the computer program and incrementing respective hardware counters 
when the plurality of addresses are accessed and a performance indicator associated 
with the plurality of addresses is encountered; and 
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performing an action in response to a determination that a predefined relationship 
between the threshold value and a combination of values obtained from the hardware 
counters is present, (emphasis added) 

Pekarich and IBMTD, taken alone or in combination, fail to teach or suggest executing the computer 

program and incrementing respective hardware counters when the plurality of addresses are accessed and 

a performance indicator associated with the plurality of addresses is encountered. 

In the abstract, Pekarich states: 

An interleaver generates a valid interleaved data address for each iteration i of 
the mapping by the interleaver without employing a multiplication operation. The 
interleaver includes an address generator comprises two counters, bit-reverse and index 
tables, and an accumulation register array. The interleaver further comprises two adders, 
two registers storing tentative address values address.sub.i and address.sub.i+1, and select 
logic including a comparator, two buffers, and a multiplexer (mux). Two counters are 
employed to allow the interleaver to generate at least one valid address for each iteration, 
and a tentative address is generated from each output value of the two counters. Each 
iteration generates an output interleaved address. A tentative address is generated by 
using a portion of the counter value as an address to select a corresponding entry from 
each of the bit-reverse and index tables and the accumulation register array. The selected 
values from the index table and accumulation register array are combined in an adder. 
The value selected from the bit-reverse table is appended to the combination of the 
selected values from the index table and accumulation register array to form the tentative 
address. The tentative address generated from the first counter value is compared with a 
threshold value, and, based on the comparison, one of the two tentative addresses is 
selected as the output interleaved address. Before beginning the next iteration, the 
accumulated value used in generating the valid output interleaved address is updated to a 
new accumulated value. If not all output interleaved addresses have been generated, the 
counters are incremented by the same increment value, the increment value dependent 
upon the comparison with ttie threshold value, and the next iteration begins. 

Thus, Pekarich is directed to an address generator for interleaving data. In Pekarich, an interleaver 
generates a valid interleaved data address for each iteration of the mapping by the interleaver without 
employing a multiplication operation. The interleaver generates at least one valid address for each . 
iteration, and a tentative address is generated from each output value of the two counters. Each iteration 
generates an output interleaved address. 

Thus, Pekarich merely describes an interleaver that generates an interleaved address for one 
sequence of data values by generating at least two counter values, each counter value having a 
predetermined offset from each other counter value. Thus, while Pekarich may teach a threshold and an 
address, Pekarich is not directed to processing instructions and does not teach or suggest executing the 
computer program and incrementing respective hardware counters when the plurality of addresses are 
accessed and a performance indicator associated with the plurality of addresses is encountered. 
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The Office acknowledges that Pekarich does not teach executing the computer program and 

incrementing respective hardware counters when pIuraHties of addresses are accessed; however, the 

Office alleges that IBMTD does. On page 1, paragraph 1, IBMTD states: 

The problem solved by this invention is the overhead of scanning memory and having 
pages stay resident in memory for long periods of times. One solution addresses this by 
releasing pages after they are read in or written out by the application, but this takes away 
the cache rehits, if they should occur. Another solution addresses memory-resident pages 
by running a daemon at a given interval, but this daemon, synod, scans all of memory, 
and if there are a large number of pages to be written out to disk, it can cause 
considerable slowdown, in addition the period of time between scans may be too long if 
the cache rehit rate takes place in a relatively small amount of time. The current method, 
LRU, does a two pass scan. On the first pass, if the page has been recently referenced, it 
will reset the reference bit, and then move to the next page. If the next page is free it will 
give it to the requesting process. If there are no pages, it will do a second pass through 
memory. 

Thus, IBMTD is directed to the overhead of scanning memory and having pages stay resident in memory 
for long periods of time. IBMTD introduces a method of fi-eeing pages from memory while allowing for 
the probability of cache hits. Thus, IBMTD is directed to clearing pages from memory that has been 
resident to long periods. 

IBMTD describes that, when a page is requested, a page frame table (PFT) for that page will be 
updated with the counter value for the hardware cycle counter. The office alleges that "each page is 
associated with a page frame table which in turn is associated with physical addresses." Thus, using the 
Office's association, IBMTD allegedly teaches that each time an address is accessed a hardware counter 
value is updated. The presently amended claim recites "executing the computer program and 
incrementing respective hardware counters when the plurality of addresses are accessed and a 
performance indicator associated with the plurality of addresses is encountered." Thus, Applicants' 
hardware counters are updated when an address is access and a performance indicator associated with the 
address is encountered. 

Furthermore, IBMTD does not teach or suggest performing an action in response to a 
determination that a predefined relationship between the threshold value and a combination of values 
obtained from the hardware counters is present. As discussed above, the hardware counters of IBMTD 
are incremented each time an address is accessed, thus, the action performed by IBMTD is performed in 
response to a hardware counter that identifies address accesses and not a hardware counter that identifies 
when the plurality of addresses are accessed and a performance indicator associated with the plurality of 
addresses is encountered. 

The Office bears the burden of establishing a prima facie case of obviousness based on the prior 
art when rejecting claims under 35 U.S.C. § 103. In re Fritch, 972 F.2d 1260, 23 U.S.P.Q.2d 1 780 (Fed. 
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Cir. 1992). Since the references fail to teach or suggest executing the computer program and 
incrementing respective hardware counters when the plurality of addresses are accessed and a 
performance indicator associated with the plurality of addresses is encountered, the Office has failed 
to establish a prima facie case of obviousness, because the Office does not show where each and every 
claim limitation is taught or fairly suggested by the applied prior art. 

The applied references do not teach or suggest each and every claim limitation; therefore, 
Pekarich and IBMTD, taken alone or in combination, do not render claim 1 obvious. Independent claims 
9 and 1 7 recite similar subject matter addressed above with respect to claim 1 and are allowable for 
similar reasons. Since claims 2-8, 10-16, and 18-23 depend from claims 1, 9, and 17, the same 
distinctions between Pekarich and IBMTD and the invention recited in claims 1 , 9, and 1 7 apply for these 
claims. Additionally, claims 2-8, 10-16, and 18-23 recite other additional combinations of features not 
taught or suggested by the references. 

Furthermore, no suggestion is present in any of the references to modify the references to include 
such features. That is, there is no teaching or suggestion in Pekarich and IBMTD that a problem exists 
for which executing the computer program and incrementing respective hardware counters when the 
plurality of addresses are accessed and a performance indicator associated with the plurality of 
addresses is encountered, is a solution. To the contrary, Pekarich appears to teach an interleaver that 
generates an interleaved address for one sequence of data values by generating at least two counter values 
and IBMTD appears to teach overhead of scanning memory and having pages stay resident in memory for 
long periods of time. 

Moreover, neither reference teaches or suggests the desirability of incorporating the subject 
matter of the other reference. That is, there is no motivation offered in either reference for the alleged 
combination. The Office alleges that the motivation would be "to reduce the expense of operations by 
allowing more immediate and more cost-effective memory management with the use of a hardware cycle 
counter and PFT cycle counter." The present invention provides for executing a computer program and 
incrementing respective hardware counters when the plurality of addresses are accessed and a 
performance indicator associated with the plurality of addresses is encountered. As discussed above, 
Pekarich appears to teach an interleaver that generates an interleaved address for one sequence of data 
values by generating at least two counter values and IBMTD appears to teach freeing pages from memory 
while allowing for the probability of cache hits. Neither reference teaches or suggests executing the 
computer program and incrementing respective hardware counters when the plurality of addresses are 
accessed and a performance indicator associated with the plurality of addresses is encountered. Thus, the 
only teaching or suggestion to even attempt the alleged combination is based on a prior knowledge of 
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Applicants' claimed invention thereby constituting impermissible hindsight reconstruction using 
Applicants' own disclosure as a guide. 

One of ordinary skill in the art, being presented only with Pekarich and IBMTD, and without 
having a prior knowledge of Applicants' claimed invention, would not have found it obvious to combine 
and modify Pekarich and IBMTD to arrive at Applicants' claimed invention, as recited in claim 1 . To the 
contrary, even if one were somehow motivated to combine Pekarich and IBMTD, and it were somehow 
possible to combine the systems, the result would not be the invention, as recited in claim 1 . The 
resulting system would still fail to execute the computer program and increment respective hardware 
counters when the plurality of addresses are accessed and a performance indicator associated with the 
plurality of addresses is encountered. 

In view of the above. Applicants respectfully submit that the Pekarich and IBMTD, taken alone 
or in combination, fail to teach or suggest the features of claims 1, 9, and 17. At least by virtue of their 
dependency on claims 1, 9, and 17, the features of dependent claims 2-8, 10-16, and 18-23 are not taught 
or suggested by Pekarich and IBMTD, whether taken individually or in combination. Accordingly, 
Applicants respectfully request withdrawal of the rejection of claims 1, 2, 4, 8-10, 12, 16-18, 20, and 23 
under 35 U.S.C. § 103. 

Moreover, in addition to their dependency from independent claims 1, 9, and 17, the specific 
features recited in dependent claims 2, 4, 8, 10, 12, 16, 18, 20, and 23 are not taught by Pekarich and 
IBMTD, either alone or in combination. For example, with regard to claims 8, 16, and 23, Pekarich and 
IBMTD, taken alone or in combination, do not teach or suggest arithmetically combining values of the 
hardware counters includes combining values in accordance with a condition indicated by a performance 
monitoring application. The Office acknowledges alleges that IBMTD teaches this feature but then states 
"IBMTD does not specifically disclose a condition indicated by a performance monitoring application, 
however, it is inherently required that the conditions associated with the process of subtraction be stored 
somewhere within the system in order for difference calculation between to the "hardware counter" and 
"PFT counter" to be possible." Applicants are claiming that the values of the hardware counters are 
arithmetically combined when a condition indicated by a performance monitoring application is met. 
Applicants are not claiming a data structure for storing a difference in calculation as alleged by the Office. 
Thus, Pekarich and IBMTD, alone or in combination do not teach or suggest arithmetically combining 
values of the hardware counters includes combining values in accordance with a condition indicated by a 
performance monitoring application. 

Thus, in addition to being dependent on independent claims 1, 9, and 17, the specific features of 
dependent claims 2, 4, 8, 10, 12, 16, 18, 20 and 23 are also distinguishable over Pekarich and IBMTD, 
either alone or in combination, by virtue of the specific features recited in these claims. Accordingly, 
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Applicants respectfully request withdrawal of the rejection of dependent claims 2, 4, 8, 10, 12, 16, 18, 20 
and 23 under 35 U.S.C. § 103. 

IV, 35 U.S.C. S 103. Alleged Obviousness - Claims 3. 6. 11. 14, 19. and 21 

The Office rejects claims 3, 6, 11, 14, 19, and 21 under 35 U.S.C. § 103(a) as being unpatentable 
over Pekarich et al. (U.S. Patent No. 6,549,998 Bl) in view of IBM Technical Disclosure, "Hardware 
Cycle Based Memory Residency" as applied to claims 1, 9, and 17 above, and further in view of Levine et 
al. (U.S. Patent No. 5,797,019). This rejection is respectfully traversed. 

Claims 3, 6, 11, 14, 19, and 21 are dependent on independent claims 1, 9, and 17 and, thus, these 
claims distinguish over Pekarich and IBMTD for at least the reasons noted above with regards to claims 

I, 9, and 17. Moreover, Levine do not provide for the deficiencies of Pekarich and IBMTD and, thus, any 
alleged combination of Pekarich, IBMTD, and Levine would not be sufficient to reject independent 
claims 1, 9, and 17 or claims 3, 6, 1 1, 14, 19, and 21 by virtue of their dependency. That is, Levine does 
not teach or suggest executing the computer program and incrementing respective hardware counters 
when the plurality of addresses are accessed and a performance indicator associated witti the plurality 
of addresses is encountered. 

In view of the above, Pekarich, IBMTD, and Levine, taken either alone or in combination, fail to 
teach or suggest the specific features recited in independent claims 1, 9, and 17, from which claims 3, 6, 

I I, 14, 19, and 21 depend. Accordingly, Applicants respectfully request withdrawal of the rejection of 
claims 3, 6, 1 1, 14, 19, and 21 under 35 U.S.C. § 103. 

V. 35 U.S.C. S 103. Alleged Obviousness - Claims 7. 15. and 22 

The Office rejects claims 7, 15, and 22 under 35 U.S.C. § 103(a) as being unpatentable over 
Pekarich et al. (U.S. Patent No. 6,549,998 Bl), IBM Technical Disclosure, "Hardware Cycle Based 
Memory Residency" in view of Levine et al (U.S. Patent No. 5,797,019) as applied to claims 3, 11, and 
19 above, and further in view of Bartfai et al. (U.S. Patent Application Publication No. 2003/0101367 
Al). This rejection is respectfully traversed. 

Claims 7, 15, and 22 are dependent on independent claims 1, 9, and 17 and, thus, these claims 
distinguish over Pekarich, IBMTD, and Levine for at least the reasons noted above with regards to claims 
1, 9, and 17. Moreover, Bartfai does not provide for the deficiencies of Pekarich, IBMTD, and Levine 
and, thus, any alleged combination of Pekarich, IBMTD, Levine, and Bartfai would not be sufficient to 
reject independent claims 1, 9, and 17 or claims 7, 15, and 22 by virtue of their dependency. That is. 
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Bartfai does not teach or suggest executing the computer program and incrementing respective hardware 
counters when the plurality of addresses are accessed and a performance indicator associated with the 
plurality of addresses is encountered. 

In view of the above, Pekarich, IBMTD, Levine, and Bartfai, taken either alone or in 
combination, fail to teach or suggest the specific features recited in independent claims 1, 9, and 17, from 
which claims 7, 15, and 22 depend. Accordingly, Applicants respectfully request withdrawal of the 
rejection of claims 7, 15, and 22 under 35 U.S.C. § 103. 

VL 35 U.S.C. S 103, Alleged Obviousness - Claims 5 and 13 

The Office rejects claims 5 and 13 under 35 U,S.C. § 103(a) as being unpatentable over Pekarich 
et al. (U.S. Patent No. 6,549,998 Bl) in view of IBM Technical Disclosure, "Hardware Cycle Based 
Memory Residency" as applied to claims 1 and 9 above, and further in view of Randall Hyde, "The Art of 
Assembly Language." This rejection is respectfully traversed. 

Claims 5 and 13 are dependent on independent claims 1 and 9 and, thus, these claims distinguish 
over Pekarich and IBMTD for at least the reasons noted above with regards to claims 1 and 9. Moreover, 
Hyde does not provide for the deficiencies of Pekarich and IBMTD and, thus, any alleged combination of 
Pekarich, IBMTD, and Hyde would not be sufficient to reject independent claims 1 and 9 or claims 5 and 
1 3 by virtue of their dependency. That is, Hyde does not teach or suggest executing the computer 
program and incrementing respective hardware counters when the plurality of addresses are accessed and 
a performance indicator associated with the plurality of addresses is encountered. 

In view of the above, Pekarich, IBMTD, and Hyde, taken either alone or in combination, fail to 
teach or suggest the specific features recited in independent claims 1 and 9, from which claims 5 and 13 
depend. Accordingly, Applicants respectfully request withdrawal of the rejection of claims 5 and 13 
under 35 U.S.C. § 103. 
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VII. Conclusion 

It is respectfully urged that the subject application is patentable over the prior art of record and is 
now in condition for allowance. The Examiner is invited to call the undersigned at the below-listed 
telephone number if in the opinion of the Examiner such a telephone conference would expedite or aid the 
prosecution and examination of this application. 

Respectfully submitted. 



DATE: 



Francis Lammes 
Reg. No. 55,353 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 385-8777 
Agent for Applicants 
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